ひとりNavigation API Advent Calendar 02日目

https://gyazo.com/1f595041648bee6e0f70b9db63b77278

これはひとりNavigation API Advent Calendarの2日目です

そもそもNavigation APIって何？という話をします

History APIやLocation APIの後継版Web APIとされるもの

主にSPA（Single Page Application）での体験改善に役立つと言われている

もともとはApp History APIと呼ばれていたみたいだった

yamanoku.iconが初めて知ったのはDomenic Denicolaがツイートして紹介してたのを見てからだった

@domenic: OMG, it's happening: app history ( https://t.co/BYPlCy0Rp1 ) controlling the loading spinner and stop button. Browser loading spinner support for your single-page app navigations!

Try it out for yourself in latest Chrome Canary! Huge kudos to Nate Chapin for the implementation!!

https://pbs.twimg.com/ext_tw_video_thumb/1471603643510145029/pu/img/k_vp8PNwUcIwYYEw.jpg

SPAだけどMPAみたいにページ遷移時にローディングスピナーを出せるぜ！っていうデモ

最初これのなにがいいのかマジで分かりませんでした（すみません）

なんでこのAPIが登場したの？

WICGのexplainerに書いてそうなので見てみましょう

せっかくなので最初のやつを参照してみる

https://github.com/WICG/navigation-api/blob/dd25bc9edf332b6ea8668d8bdb7911d8b298a4e3/README.md

コミットを見るとhttps://github.com/slightlyoff/history_api からimportしてきたっぽい

提案、Dominic Gannawayが書いたのかと思い込んでたが違ったのか…

https://github.com/slightlyoff/history_api/blob/e0112329e6394e9323d95f8524483a3d3e42e29b/README.md

これがホントの初期案

Application Developers face a range of challenges when performing client-side updates to dynamic web apps including (but not limited to):

Lack of clarity on when to rely on base URL, query parameters, or hash parameters to represent "persistent" state

Difficulty in serializing & sharing "UI state" separate from "application state"

Complexity in capturing browser-initiated page unloading for client-side routers

Tricky coordination problems between multiple page components which may each want to persist transient UI state but remain largely unaware of each other

Difficulty in understanding one's location in, and predicting effects of chagnes to, the HTML5 History API stack due to potentially co-mingled origins

Nani翻訳する

アプリケーション開発者は、動的なウェブアプリケーションのクライアントサイドを更新する際に、以下を含む（ただしこれらに限定されない）さまざまな課題に直面します。

「永続的な」状態を表現するために、ベースURL、クエリパラメータ、またはハッシュパラメータのどれに頼るべきかの判断が難しい

「アプリケーションの状態」とは別に「UIの状態」をシリアライズして共有することが難しい

クライアントサイドのルーターにおいて、ブラウザが開始するページのアンロードを捕捉するのが複雑である

複数のページコンポーネント間で、調整が難しい問題が発生する。それぞれのコンポーネントは、一時的なUIの状態を保持したいかもしれないが、互いをほとんど認識していない可能性がある

HTML5 History APIスタックにおける自身の位置を理解したり、変更の影響を予測したりすることが難しい。これは、起点（オリジン）が混在している可能性があるためである

雑な要約をするとSPAでの状態管理やページの状態復元が既存のHistory APIだけだと難しくなってきたのでよりマシなAPIとして設定したいよ、って感じと理解

ちゃんとフロントエンドやっていくぜ！というモチベーションが感じられていいね

ところでなぜ理解の浅いyamanoku.iconがこのAPIに注目しているの？

前提としてSSGが好きなMPA信仰者です

SPAはSPAじゃなきゃいけない体験が必要ならいいんじゃないのって肌感

でもログイン必要なユーザーが触れるってSSRでやるのがベターじゃないですか

しかしSSRってすんなりとした理解に落とし込むには技能が必要ですよね

だからあんまりフロントエンド開発を過度に複雑にしたくないというのはある

あといちユーザーとしてブラウザバックとかBFCacheが効いてない状態で入力してた状態やスクロール位置の状態がなくなってるのなかなかのヘイトがあるんです

なのでそこに歩み寄ってくれるAPIなのでマシになるかなという期待があります

SPAでのスクリーンリーダーへの画面遷移で通知するテクニックで悩んでいます

Route Announcerというテクニックによるものでなんとか実現できるのが最適解だと思っている

2023年にまとめたけどここから大きく変わってないと思う

それがNavigation APIによって改善できるようになる期待がある

SPAというものが敬遠されていたがここが改善されると可能性は広がる

画面遷移のアクセシビリティ課題を解決しうる Navigation API への期待 - Google Slides

JSConfJP 2023で発表した内容です

Interop 2025で対象に選ばれたAPIだから

これまでプロポーザルとして出されても選ばれてなかった

今年ついに対象になった

選ばれつつも2025年の進捗がなかなか現れず（Chromium以外テスト通ってない状態）ここ1ヶ月くらいでようやく圧倒的進捗を出していた

順調にテストを潰していけば来年よりNewly Baselineとしてクロスブラウザで使えるようになっていきそう

フレームワーク、ルーターライブラリが注目している

Next.jsやReact Router、TanStack Routerが注目してる

上記は今のところ業務では使ってないがNuxtも関係あるだろうなと思ってる

ルーター処理がWeb標準が担えるとルーター側は実装に考慮しなくてよい

SignalsがWeb標準になったらFine-Grained Reactivityなライブラリはうれしくなるやつ

注目してる、相当しんどかったんだろうかな…という気持ちはある

来年に向けての使用していくきっかけの布石としてこのアドベントカレンダーが活用していくためのきっかけになればと思って書き始めています